Referring to FIGS. 1A and 1B, in applications such as video and audio conferencing in a communication network 10, one of the desired modes of operation is to have a single participant 12a be the speaker at any one time, i.e., to “gain the floor.” Therefore, in most instances, the conferencing equipment provides a mechanism to arbitrate who should gain the floor among all the participants 12a-12c of the conference call/communication 14. (In this context, “participant” refers to an electronic device/terminal communicating over the network for the conference call.) In general, a floor control server (FCS) 16 is deployed in the system to be the arbitrator of a conference call. Logical control channels are established between each conference participant 12a-12c and the server 16 for the transmission of control messages that regulate the conferencing. The control messages vary from system to system, with different levels of functionality.
According to a basic control method, when a participant 12a wants to gain the floor, it sends a “floor-request” message 18 to the server 16. It is possible that multiple participants request the floor at roughly the same time. Upon receipt of the floor-request(s) 18 from the participant(s), the server 16 determines the floor winner based on a designated process. The process used to determine the floor winner is referred to as the floor control or floor determination algorithm. Once the floor winner is determined, the server 16 sends a “floor-grant” message 20 to all the participants, or to a subset of all the participants (e.g., only to the floor winner, only to participants who have submitted a floor control request message, or the like). This message includes the identity of the floor winner. Each participant that has requested the floor may wait for the floor grant message 20 to determine whether it has won the floor, or it may receive an implicit grant denial if it does not receive the floor within a predetermined period of time. The floor winner is enabled for transmitting data/media 22 (e.g., speech, other audio, and/or video) over the network 10 to the other participants. The data traffic is logically separate from the floor control messages.
When a participant terminal 12a is directed to stop transmitting data and yield the floor (e.g., the user stops speaking, or a transmit pressel or other switch is deactivated), it sends a “floor-release” message 24 to the server 16. The server 16 propagates this message (or sends another message 26) to the other conference participants for informing them that the floor is again open. If none of the participants want the floor, the server 16 may, after some time, periodically choose to broadcast a “floor-idle” 28 message to the participants.
“Contention” occurs when two or more participants request the floor at the same time. The floor control algorithm is resident on the server 16 for selecting a floor winner among all the requests. An example of floor contention is shown in FIG. 2. As indicated, the server 16 receives floor request messages 18a, 18b from two participants 12a, 12b, respectively. After carrying out the floor control algorithm/process, the server 16 grants the floor to the second participant 12b, transmitting a floor-grant message 20 to this effect.
There are many variations of the above procedure. For example, a server may decide to send a “floor-denied” message to all participants who have requested the floor but fail to win it, instead of relying on the floor-grant message indicating that another participant has won the floor.
Certain communication networks utilize a hierarchical server structure 30, as shown in FIGS. 3A and 3B. Here, to provide load balancing and to improve resiliency, a number of load servers are deployed in a hierarchical tree topology. Logically, floor control of the conference call is still executed at a single master server 32, at the root of the tree. Each server executes its own floor control algorithm. When an auxiliary server 34a-34e determines a local floor winner, it sends a floor request message to its upstream server on behalf of the floor winner. The upstream server then determines its local floor winner from floor-requests received from participants 36 and from downstream servers directly connected to it. The master server 32 determines the global floor winner based on the floor requests directed to it, and broadcasts a floor-grant message to all downstream servers directly connected to the master server 32. The downstream servers propagate this message using the same process. Eventually, all participants of the conference receive the floor-grant message.
A similar procedure applies to the floor-idle message (broadcast down) and the floor release message (propagate-up, no contention).
Regarding floor priority, the basic procedure described above assumes that all floor requests have equal priority. In actual applications, some floor requests have higher priorities than others. For example, in a public safety network, a floor request generated by a policeman reporting a fire may have a higher priority than normal, non-emergency requests. Priority of the floor requests can be encoded in the floor-request messages. Usually included in the floor request message are two fields: contention priority and preemptive priority. (Some implementations may have only one of the two fields.) The present disclosure adopts the convention that a higher value of these fields will indicate higher priority.
Contention priority indicates the priority of the floor request and is used by the server to determine the floor winner. Preemptive priority is more severe. When a server 16 receives a floor request with a preemptive priority “N,” if N has a higher priority than the contention priority of the current speaker (e.g., the terminal/participant currently granted the floor), the server terminates the floor of the current speaker and awards the floor to the participant with preemptive priority “N”. If multiple floor request messages with preemptive priorities greater than the contention priority of the current speaker are received, the server terminates the floor of the current speaker and awards the floor to the participant with the highest preemptive priority. For a given participant terminal, the contention and preemptive priorities of a floor request do not have to be equal. However, the contention priority will typically be at least the value of the preemptive priority. It may also be the case that preemptive priorities are not compared to contention priorities (e.g., there may be rules in which preemptive priorities always outrank contention priorities), but rather only with preemptive priorities of other requests.
Certain performance criteria are associated with floor control processes in communication networks. One such criterion in push-to-talk applications is the floor control response time. This is measured as the time between when a participant sends a floor request message to the time when a floor-grant message is received. For many applications such as push-to-talk in public safety networks, this is a critical performance parameter.
Another criterion is the “fairness” of the floor control algorithm. Here, the definition of fairness is that, for the same priority, participants should have a generally equal probability of winning a floor request over a designated time period. In other words, on a time average basis, participants should have equal chances of gaining the floor.
The most simple floor control algorithm is a “first come first served” (FCFS) system. In such a system, the server grants the floor to the originator of the first floor request to be received. Apart from its simplicity, the FCFS system has a good response time, since there is no waiting involved at the server. However, FCFS systems have poor fairness characteristics. For example, there may be two participant terminals 12a, 12b positioned at different locations in the network, wherein the time elapsed from floor request message transmission to server reception may be shorter for terminal 12a. In this case, terminal 12a will be awarded the floor more frequently than terminal 12b in situations where both transmit a floor request at similar times. Thus, an FCFS system favors participants that have a shorter transmission delay over those with longer delays.
One way of introducing fairness is for the server, upon receiving the first floor request, to wait some time for additional requests from other participants before making a decision to award the floor to one of the participants. In this way, greater fairness can be achieved. The downside, however, is that this method reduces the response time since the server has to wait before it makes a decision.
In simple systems, the server does not have memory. Therefore, a participant that loses a floor request must generate a new floor request when the current speaker leaves the floor. In more complex systems, the server may decide to put all the requests on a queue. The server then awards the floor to the requests that have been queued up. Such algorithms are referred to as “queued” systems. Generally, queued systems have good characteristics for both response time and fairness. However, an additional layer of control may be required for handling the queue. For example, in the case of first and second users in a public safety network application, both may request the floor for reporting the same incident, such as a fire. If the first user wins the initial floor control and reports the incident to all participants, the second user may no longer want the floor because the incident is already reported. Thus, it may be desirous to include additional control messages in a queued system so that a participant can indicate to the server that although the user had requested the floor previously, the user no longer wants the floor. This would add additional complexity to both the server and the terminal equipment.
In another example, many push-to-talk applications are implemented across wireless networks. After a server puts a participant's request on the queue, the participant may wander out of the network's coverage area. In this case, the server may award the floor to a participant who is no longer active in the network. One solution for such situations is to have the server keep track of the active participants of a conference. When the server detects that a participant is no longer available, the server deletes any requests from that user in its queue. The mechanism for detecting when participants with queued requests leave the network would add additional complexity to the system. For applications such as public safety networks, where talk groups can easily span hundreds of participants, this may become impractical.
In another solution, instead of keeping track of a participant, the server ascertains the presence of the participant when it awards the floor to that participant. Again, this increases the complexity of the control protocol. Also, if the participant is not in the system, this increases the response time since the floor is being awarded to a participant that is no longer present. Additionally, some networks (e.g., wireless networks) cannot keep track of participants leaving the network. Then, the server has to ascertain the presence of the participant, or detects its absence. In these instances, additional delays are incurred.
Thus, robust queued systems, in general, have more control messages and involve more complex control procedures. In addition, queued systems do not scale well when the number of participants is large.